window.open() 的作用是创建一个新的浏览器窗口用来打开相关的资源，这是一个原生的 Javascript API 接口。有关 window.open() 的基本使用可以参考 mozilla 提供的  API 文档：window.open 。

大部分现代的浏览器（泛指 Chrome / Firefox / IE 10+ / Safari）都默认开启了阻止弹出窗口的策略，原因是 window.open 被广告商滥用，严重影响用户的使用。这个阻止弹出窗口的操作，并不是直接封杀 windw.open()，而是会根据用户的行为来判断这次 window.open() 是否属于流氓操作。

如果是由用户触发的动作所引起的 window.open 就不会被浏览器所阻止，比如写在 onclick 这些事件 handler 里的，但如果是代码自己触发的就会被阻止。

大家可以打开以下两个页面进行测试：

如果你的浏览器是默认的设置（开启了阻止弹出窗口），那么你就能发现，demo1 中点击完按钮后窗口就直接弹出来了，而 demo2 则在两秒后会被浏览器告知有一个窗口被阻止了。从 demo 中看起来很浅显易懂，也很能明白浏览器们的做法。

但是问题来了，如果是用户点击后，我们的程序需要运行一些代码然后才执行 window.open() ，这种情况是否会被阻止呢？ （实现开发中的各种情况各种需求都十分操蛋。）

对于这种情况，我们来做个简单的例子，就是点击按钮之后将 window.open() 延迟一下，看看浏览器们有什么反应。我们可以使用 setTimeout() 来做这个的处理。相关代码片段：

当延迟 100 毫秒的时候，Chrome 会让窗口弹出，但是当延迟 2000 毫秒（即 2s ）时这个操作会被阻止。经过多次试验，我发现这个临界值是 1000 毫秒。

1000 毫秒的时候允许弹出框， 1001 毫秒的时候被阻止。

大家可以通过根据 demo3 （点击这里）（本着用户都是傻逼才加上这个）来测试，修改代码中的延迟值来试。这个临界值，在 Safari / Chrome / Firefox (都是 for Mac) 下测试，均通过，都是 1001 毫秒的时候被阻止。

结果拿到 IE 11 下测试，发现就算是 1 毫秒都会被阻止。（意料之中）

我们先撇开 IE 的差异，我尝试把 setTimeout 转换成一些逻辑的代码放在 window.open() 前面，比如：

弄完之后得出的小结是：

不过由于各种原因，我们的 window.open() 会经常性的被阻止掉，虽说浏览器本身有对这个阻止事件做通知，但是由于用户是白痴的（不要问我为什么），我们最好也在界面上做一些通知告知用户。

我们可以利用 window.open () 的 return 值来判断 window.open 的执行情况，window.open 的返回值是一个打开的新窗口对象的引用， 如果 window.open 的操作被阻止，那么它的返回值就是 undefined 。

那么我们就可以利用返回值来判断这个 window.open 操作是否被正常的执行。

大家可以看到上面的 demo1 / demo2 有一个 feedback 的文字，就是根据 window.open() 的返回值来做判断的。我还是把部分代码发一下吧：

这样的话，就可以在界面上比较清晰的告知用户是怎么回事了。

如果你的用户确实是傻逼的话，那么你可以根据用户的浏览器版本，来告诉用户怎么解除在他的浏览器中解除这个玩意。。。

大家知道，如果父子窗口（当前窗口为父，window.open() 后的窗口为子）符合同源策略的话，父窗口里面是可以控制子窗口的，包括刷新、执行函数、跳转链接。

那么这里有一个方法可以绕开浏览器阻止弹窗的机制（针对桌面），就是点击按钮后先打开一个符合同源策略的 window ，然后再执行你相关的逻辑包括 Ajax 请求等。完成之后，再来处理子窗口。假设 windowRef 是 window.open() 的返回值。

但是这种奇葩方法的体验不是很好，就是会预先弹出一个窗口，如果你运行的逻辑代码很长的话，用户会不知道干啥，可能会关闭了窗口。当然你们也可以在子窗口那里先留下一些文字，告诉用户不要关闭，请等待之类的。

原文地址： lingyi.red/window-open…